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Dear Sir: 

SECOND AMENDED APPELLANT'S BRIEF UNDER 37 C.F.R. 41.37 

The following is the Second Amended Appellant's Brief, submitted under the provisions of 
37 C.F.R. 41.37 in reply to the Notification of Non-Compliant Appeal Brief mailed on April 5, 2007. 
The Appellant's Brief was originally filed on December 5, 2006, and the $250 fee required by 37 
C.F.R. 41 .20(b) was submitted at that time. The first amended Appellant's Brief was submitted on 
February 5, 2007, in reply to a Notification of Non-Compliant Appeal Brief mailed on January 9, 
2007. This submission is being made in a timely fashion and no fee is believed due. If any fee is 
due at this time, please charge the fee to deposit account no. 07-1732. 
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Real Party in Interest 

The real party in interest is the assignee of record, i.e. Navaho Networks Inc., 170 University 
Avenue, Suite 602, Toronto, Ontario Canada, M5H 3H3. 

Related Appeals and Interferences 

There are no related appeals or interferences that will directly affect, be directly affected by, 
or have a bearing on the present appeal. 

Status of Claims 

Claims 1, 4-26, and 28-36 stand rejected. Clain[is 2, 3 and 27 are cancelled. Claims 1, 4-26 
and 28-36 are being appealed. 

Status of Amendments 

No amendments have been made subsequent to the office action response of February 13, 

2006. 

Summary of claimed subject matter 

Claim 1 

A facilitation server (figure 7: 78) receives information (such as a vendor identifier, a 
purchase amount, and a data product access URL and password) relating to a pending transaction 
between a vendor server (74A) and a client (90A) (see specification at page 11, lines 12 to 17). 

The facilitation server sends this information on to a transaction server system (88) which 
stores the information with a transaction identifier and determines appropriate private network 
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access information, such as an appropriate chargeable telephone number (e.g., a 900 number) based 
on the purchase amount. The transaction server system stores the telephone number with the other 
information and retums the transaction identifier and telephone number to the facilitation server 
(page 11, lines 19 to 25). 

The facilitation server provisions a set of computer readable instructions (e.g., an applet) 
with the transaction identifier and the telephone number and sends the client this set of computer 
readable instructions over the public Intemet (22) (page 11, line 27 to page 12, line 15). The client 
(90 A), under control of the set of computer readable instructions, dials and estabUshes a connection 
to the telephone number over a telephone network (84); sends the transaction identifier over the 
connection; receives a message over the connection with a URL and password; drops the 
connection; connects to the URL over the public Intemet; and displays the password (page 12, lines 
16 to 30 and page 13, lines 6 to 12). 

Claim 12 

A facilitation server (figure 7: 78) receives information (such as a vendor identifier, a 
purchase amount, and a data product access URL and password) relating to a pending transaction 
between a vendor server (74A) and a client (90A) over a public Intemet (22) (see specification at 
page 11, lines 12 to 17). 

The facilitation server sends this on to a transaction server system (88) which stores the 
information with a transaction identifier and determines appropriate private network access 
information, such as an appropriate chargeable telephone number (e.g., a 900 number) based on the 
purchase amount. The transaction server system stores the telephone number with the other 
information and retums the transaction identifier and telephone number to the facilitation server 
(page 11, lines 19 to 25). 

The facilitation server sends a set-up message to the client, which is a set of computer 
executable instructions (e.g., an applet) for determining resources of the client for connection to the 
telephone network (page 11, line 29 to page 12, line 13). 

The facilitation server provisions a transaction message, which is another set of computer 
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readable instructions, with the transaction identifier and the telephone number and sends the client 
this other set of computer readable instructions over the public Intemet (22) (page 1 1 , line 27 to page 
12, line 15). The client (90A), under control of the second set of computer readable instructions, 
dials and establishes a connection to the telephone number over a telephone network (84); sends the 
transaction identifier over the connection; receives a message over the connection with a URL and 
password; drops the connection; connects to the URL over the public Intemet; and displays the 
password (page 12, lines 16 to 30 and page 13, lines 6 to 12). 

Claim 21 

A facilitation server (figure 7: 78) receives information (such as a vendor identifier, a 
purchase amount, and a data product access URL and password) relating to a pending transaction 
between a vendor server (74A) and a client (90A) over a public Intemet (22) (see specification at 
page 11, lines 12 to 17). 

The facilitation server sends a set-up message to the client with a set of computer executable 
instructions (e.g., an applet) for determining resources of the client for connection to a telephone 
network (84) (page 11, line 29 to page 12, line 13). 

Claim 22 

A transaction server system (figure 7: 88) receives information over a secure link from a 
facilitation server (78) (such as a vendor identifier, a purchase amount, and a data product access 
URL and password) relating to a pending transaction between a vendor server (74A) and a client 
(90A) (see specification at page 10, lines 1 1 to 13 and page 11, lines 12 to 17). 

The transaction server system (88) stores the information with a transaction identifier and 
determines an appropriate chargeable telephone number (e.g., a 900 number) based on the purchase 
amount. The transaction server system stores the telephone number with the other information. 
(Page 11, lines 19 to 24.) 

The transaction server system retums the transaction identifier and telephone number to the 
facilitation server over the secure link (page 11, lines 24 to 25). 
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Claim 26 

A client computer (figure 7: 90 A) receives a set of computer executable instructions (from 
the facilitation server (78)) provisioned with a transaction identifier and a telephone number (page 
11, line 27 to page 12, line 15). 

The client (90A), under control of the second set of computer readable instructions, dials and 
establishes a connection to the telephone number over a telephone network (84); sends the 
transaction identifier over the connection; receives a message over the connection with a URL and 
password; drops the connection; connects to the URL over the public Intemet; and displays the 
password (page 12, lines 15 to 30 and page 13, lines 6 to 12). 

Grounds of rejection to be reviewed on appeal 

Whether claim 36 satisfies the written description requirement of 35 USC 1 12. 

Whether claims 26 and 36 are indefinite and therefore fail to satisfy 35 USC 1 12. 

Whether claims 1, 4-16, 18-21, 34 and 35 are unpatentable under 35 USC 102(b) as 
anticipated by US5,778,173 to Apte. 

Whether claims 22 to 32 are unpatentable under 35 USC 102(b) as anticipated by 
EP0926,611 toFurman. 

Whether claim 17 is unpatentable under 35 USC 103(a) as obvious over Apte in view of 
US5,729,594 to Klingman. 

Whether claim 26 is unpatentable under 35 USC 103(a) as obvious over Apte in view of 
US2003/0195843 to Matsuda. 

Whether claim 29 is unpatentable under 35 USC 103(a) as obvious over Furman in view of 
Matsuda. 

Whether claim 33 is unpatentable under 35 USC 103(a) as obvious over Furman in view of 
US6,675,008 to Paik. 

The Examiner rejected claim 27 under 35 USC 120(e) as anticipated by US6,704,873 to 
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Underwood. However, as this claim was canceled in the response of February 13, 2006, this 
objection is moot. 

Argument 

Claims L 4, 10, 16, 18 to 20, 34, and 35 

In Apte "[t]he user browses public sites on the WWW and ultimately decides to purchase a 
product or service from a vendor. . . The vendor generates a purchase order number in response to the 
user's request and transmits the order number to both the transaction server and the user's computer 
10. The vendor directs the user to contact the appropriate transaction server and may additionally 
provide the user with the server's telephone number" (col. 3, lines 41 to 50). Then "communication 
between the WWW and the computer is suspended . . . the computer establishes communication with 
the transaction server over the secure network." (Col. 3, lines 60 to 65.) "[T]he user is provided 
with software to be executed on the computer 10 which automatically performs the transition in 
communication from the WWW 12 to the transaction server 19" (col. 3, lines 15 to 18). "[AJfter 
communication has been established with the transaction server, the user provides the server with 
the purchase order number . . . and ... a credit card number" (col. 4, lines 30 to 37). 

Claim 1 requires "provisioning a set of computer readable instructions with transaction- 
specific information comprising said transaction identifier and said private network access 
information" and "sending a message addressed to said client over said public Intemet with said set 
of computer readable instructions having said transaction-specific information, said set of computer 
readable instructions comprising access instructions for connecting said client to said transaction 
server system on said private network ". 

Applicant submits Apte lacks these features. 
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In his final action of May 9, 2006, the Examiner asserts these features are in Apte. In this 
connection, the Examiner states Apte discloses "the vendor directs or instructs the user computer to 
contact the appropriate transaction server" (emphasis added; see page 3, lines 1 to 2 of the final 
action). Applicant submits this statement is not correct. In fact Apte discloses: "The vendor directs 
the user to contact the appropriate transaction server" (emphasis added; see col. 3, lines 47 to 48 of 
Apte). This is different: it means the vendor (server) directs the person who is using computer 1 0 to 
contact the transaction server. While Apte does not specify how this is done, it could perhaps be 
accomplished by, for example, the vendor sending an appropriate textual message for display on the 
screen of the user computer. Thus, the vendor does not direct the user computer to contact the 
transaction server, as, for example, by sending computer readable access instructions to the user 
computer, as contemplated by subject claim 1. 

In his final action, the Examiner also states Apte discloses that "the computer looks up or 
searches for the transaction server telephone number". And that "[t]he user computer is incapable of 
searching or looking up the transaction server's telephone number if there is no executable code that 
instructs the computer to do so." (See page 3, lines 3 to 6 of the final action.) Applicant submits 
that, even if the Examiner's assertion is true, it does not show Apte discloses the user computer 
receives these executable instructions over the Internet as is required by claim 1 . Nor does it show 
that these instructions are received with transaction-specific information, as is also required by claim 
1. Further, claim 1 states that the transaction-specific information comprises the transaction 
identifier and private network access information. If Apte received computer readable instructions 
that already included private network access information, there would be no purpose in searching for 
this information. 

For all of these reasons, it is submitted any code in Apte's user computer for searching for a 
telephone number would not meet the limitations of claim 1 , or claims 4, 1 0, 1 6, 1 8 to 20, 34, and 35 
which depend from claim 1 . 
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Applicant therefore submits claims 1 4, 10, 16, 18 to 20, 34, and 35 are not anticipated by 

Apte. 
Claim 5 

Claim 5 requires that the "private network access information comprises a flat rate telephone 
number". The Examiner points to col. 3, lines 39-59 of Apte as showing this feature. In fact, in the 
referenced portion, Apte states "The vendor. . . may additionally provide the user with the server's 
telephone number, which may, for example, be an 800 number." (Col. 3, lines 47 to 50.) It is 
submitted this does not show the feature of claim 5 and, therefore, Applicant submits claim 5 is not 
anticipated by Apte. 

Claim 6 

Claim 6 requires that the "private network access information comprises a fixed charge per 
minute telephone number and a number of minutes". The Examiner points to col. 3, lines 39-59 of 
Apte as showing this feature. In fact, in the referenced portion, Apte states "The vendor. . . may 
additionally provide the user with the server's telephone number, which may, for example, be an 800 
number." (See col. 3, lines 47 to 50.) It is submitted this does not show the feature of claim 6 and, 
therefore, Applicant submits claim 6 is not anticipated by Apte. 

Claims 7 to 9 

Claim 7 requires "prior to said sending" (of the message with the set of computer readable 
instructions with transaction-specific information) "sending a location of said set of computer readable 
instructions over said public Intemet". 

The Examiner points to col. 4, lines 8-29 as showing this feature. In fact, Apte states "the 
computer first uses the Universal Resource Locator (URL) of the vendor and attempts to retrieve the 
phone number for its transaction server from a locally stored directory. If the number is not found, the 
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computer automatically dials the directory located on the secure network and downloads the 
appropriate telephone number" (col. 4, lines 18 to 24). Therefore, the Examiner's assertion Apte 
shows the features of claim 7 is traversed. 

It is therefore submitted that claim 7, and claims 8 and 9 which depend therefrom, are not 
anticipated by Apte. 

Claim 11 

Claim 1 1 requires "said set of computer readable instructions comprise a second code segment 
which, when loaded into said processor of said cUent, cause said client to pass said transaction-specific 
information to said transaction server system." 

The Examiner points to col. 1 , lines 45-67; col. 3, lines 1 5-27; and col. 4, lines 30-43 of Apte as 
showing this features. In fact, in Apte, "after communication has been established with the transaction 
server, the user provides the server with the purchase order number" (col. 4, lines 30 to 32). Thus, the 
user manually provides the transaction server with the purchase order number rather than any code 
segment on the user' s computer automatically providing this information to the transaction server. As 
such, it is submitted that Apte does not show the features of claim 1 1 . 

It is therefore submitted that claim 1 1 is not anticipated by Apte. 

Claim 12 

In Apte "the user is provided with software to be executed on the computer 10 which 
automatically performs the transition in communication from the WWW 12 to the transaction server 
19" (col. 3, lines 15 to 18). 
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However, amended claim 12 requires ''sending a message addressed to said client over said 
public Intemet with a set of computer readable instructions having transaction-specific information" 
and ''prior to said sending said transaction message, sending a set-up message addressed to said 
client over said public Intemet with a set of computer executable instructions for determining 
resources of said client for connecting to said private network.". 

Applicant therefore submits Apte lacks these features. 

In his final action of May 9, 2006, the Examiner asserts these features are in Apte. In this 
connection, the Examiner points to col. 3, lines 15-27 and col. 4, lines 44-55 of Apte and sets out a 
quote: "the software is downloaded and setup occurred prior to sending" (see page 3 of the final 
action at the fourth and third to last lines). Applicant asserts that this purported quote appears no 
where in Apte. Nor do the lines of Apte referenced by the Examiner suggest the above-quoted 
features of claim 12. 

The Examiner also states: "the user computer in Apte . . . does a setup step when it first uses 
the URL of the vendor and attempt[s] to retrieve the phone number for the transaction server. . . Thus 
Apte[,] does determine the client resources for connecting to said private network" (see page 3, third 
to last line to page 4, line 5 of the final action). 

Even if the Examiner is correct that Apte's user computer (client) 1 0 does a setup step when 
it first uses the URL of the vendor, this would not meet the claim 12 feature of "sending a set-up 
message addressed to said client over said public Intemet with a set of computer executable 
instructions for determining resources of said client for cormecting to said private network". 

For all of these reasons, it is submitted that Apte does not meet the limitations of claim 12. 
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Claim 13 

Claim 13 requires "receiving from said client over said public Internet an indication of 
resources of said client and provisioning said set of computer readable instructions based, in part, on 
said indication of resources." 

The Examiner relies on col. 3, lines 15-27 as showing this feature. In fact, Apte shows "the 
user is provided with software to be executed on the computer 1 0 which automatically performs the 
transition in communication from the WWW 12 to the transaction server 19" (col. 3, lines 15 to 18). 
This is wholly unrelated to what is claimed in claim 13. 

Applicant therefore submits that claim 13 is not anticipated by Apte. 

Claim 14 

Claim 14 requires "said set of computer readable instructions further comprises instructions 
for determining resources of said client for connecting to said private network." 

The Examiner relies on col. 3, lines 15-27 as showing this feature. In fact, Apte shows "the 
user is provided with software to be executed on the computer 1 0 which automatically performs the 
transition in communication from the WWW 12 to the transaction server 19" (col. 3, lines 15 to 18). 
This is wholly unrelated to what is claimed in claim 14. 

Applicant therefore submits that claim 14 is not anticipated by Apte. 

Claim 15 

Claim 15 requires "sending said information relating to a pending transaction to said 
transaction server system over a secure link prior to said receiving a transaction identifier and 
private network access infomiation." 
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The Examiner relies on col. 1, lines 45-67 of Apte as showing this feature. In fact, Apte 
shows "a transaction identification number is received from the remotely located server over the 
open network and subsequently. . . [c]ommunication is established between the user and a transaction 
server ... over a communication network isolated from the open network. The transaction 
identification number is transmitted to the transaction server over the communication network" (col. 
1 , lines 5 1 to 59). Clearly, then, the transaction server is accessed over a private network first and 
then the transaction server is given information relating to the pending transaction. This is the 
opposite of what is required by claim 15. 

Applicant therefore submits that claim 15 is not anticipated by Apte. 

Claim 17 

In Apte "[t]he user browses public sites on the WWW and ultimately decides to purchase a 
product or service from a vendor. . . The vendor generates a purchase order number in response to the 
user's request and transmits the order number to both the transaction server and the user's computer 
10. The vendor directs the user to contact the appropriate transaction server and may additionally 
provide the user with the server's telephone number" (col. 3, lines 41 to 50). Then "communication 
between the WWW and the computer is suspended . . .the computer establishes communication with 
the transaction server over the secure network." (Col. 3, lines 60 to 65.) "[T]he user is provided 
with software to be executed on the computer 10 which automatically performs the transition in 
communication from the WWW 12 to the transaction server 19" (col. 3, lines 15 to 18). "[A]fter 
communication has been established with the transaction server, the user provides the server with 
the purchase order number . . . and ... a credit card number" (col. 4, lines 30 to 37). 

In Klingman, a user may access a TRY server to obtain a software demo. The TRY server 
has a 900 number that the user may call to access a BUY server in order to purchase a hardware or 
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software product (see col. 10, lines 35 to 41). 

Claim 17 requires "provisioning a set of computer readable instructions with transaction- 
specific information comprising said transaction identifier and said private network access 
information" and "sending a message addressed to said client over said public Intemet with said set 
of computer readable instructions having said transaction-specific information, said set of computer 
readable instructions comprising access instructions for connecting said client to said transaction 
server system on said private network 

Applicant submits both Apte and Klingman lack these features. 

It is therefore submitted that no prima facie case of obviousness has been made out against 
claim 17. 
Claim 21 

Claim 2 1 requires "sending a message addressed to said client over said public Intemet with 
a set of computer executable instructions for determining resources of said client for connecting to a 
private network.". 

In his final action of May 9, 2006, the Examiner asserts these features are in Apte. In this 
connection, the Examiner points to col. 3, lines 15-25. But this portion of Apte discloses, instead: 
"the user is provided with software to be executed on the computer 1 0 which automatically performs 
the transition in communication from the WWW 12 to the transaction server 19" (col. 3, lines 15 to 
18). Therefore, Applicant traverses this position of the Examiner. 

It is therefore submitted that Apte does not meet the limitations of claim 21 . 
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Claims 22 to 24. 28. 30, 3 L and 32 

Claim 22 requires "determining an appropriate chargeable telephone number based upon said 
purchase amount". 

The Examiner relies upon paragraphs 20 and 21 of Furman and figure 2A as showing this 

feature. 

With reference to figures 2A to 2C, in Furman, a "customer places order" (202) and in 
response the "vendor transmits transaction identifier and 900 # to customer" (206). The "customer 
places telephone call to specified 900 #" (208) and "transmits transaction identifier to audio 
browsing platform" (216). The "audio browsing platform transmits transaction identifier to vendor 
server" (222) and the "vendor server transmits price to audio browsing platform" (226). The "audio 
browsing platform communicates price to customer" (228). If the price is accepted (232), the "audio 
browsing platform transmits amount to bill customer to 900 billing node" (240). 

As explained in paragraph 21 of Furman: "The 900 telephone number may be shared by a 
number of vendors" or "the 900 number could be dedicated to a particular vendor such that each 
vendor has its own dedicated 900 number." 

Therefore, in contrast to claim 2 1 , in Furman the 900 number is selected independently of the 
purchase amount. 

It is therefore submitted that claim 22, and claims 23, 24, 28, 30, 31, and 32 which depend 
therefrom, are not anticipated by Furman. 



Claim 25 

Claim 25 recites "wherein said telephone number is a fixed charge per minute number and 
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wherein said determining further comprises determining a number of minutes based on said purchase 
amount and storing said number of minutes." 

The Examiner relies upon paragraph 9 of Furman as showing this feature. But paragraph 9 
states that the "telephone number . . . results in a charge. If the amount is variable. . . if the customer 
accepts the charges. . . the validation system send[s] the billing amount to the billing node". This is 
not what is required by claim 25. 

Therefore, it is submitted that claim 25 is not anticipated by Furman. 

Claim 26 

In Apte "[t]he user browses public sites on the WWW and ultimately decides to purchase a 
product or service from a vendor. . . The vendor generates a purchase order number in response to the 
user's request and transmits the order number to both the transaction server and the user's computer 
10. The vendor directs the user to contact the appropriate transaction server and may additionally 
provide the user with the server's telephone number" (col. 3, lines 41 to 50). Then "communication 
between the WWW and the computer is suspended . . .the computer establishes communication with 
the transaction server over the secure network." (Col. 3, lines 60 to 65.) "[T]he user is provided 
with software to be executed on the computer 10 which automatically performs the transition in 
communication from the WWW 12 to the transaction server 19" (col. 3, lines 15 to 18). "[AJfter 
communication has been established with the transaction server, the user provides the server with 
the purchase order number . . . and ... a credit card number" (col. 4, lines 30 to 37). 

Claim 26 recites, after establishing a connection to a telephone number and sending a 
transaction identifier: "receive a message over said coimection with a universal resource locator 
(URL) and password; drop said connection; connect to said URL over a public Intemet; and display 
said password". 
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Applicant asserts that Apte does not disclose any of these features. 

The Examiner states that Apte does discloses the quoted features except for the display of a 
password and that Matsuda discloses this last feature. For example, the Examiner points to col. 4, lines 
8-25 of Apte as showing the feature of "receive a message over said connection with a universal 
resource locator (URL) and password". But at this portion of Apte "the computer first uses the 
Universal Resource Locator (URL) of the vendor and attempts to retrieve the phone number for its 
transaction server" (col. 4, lines 19 to 21). Thus, while Apte uses an Intemet connection to find a 
telephone number, claim 26 recites using a telephone connection to find a URL. In other words, the 
feature of claim 26 is exactly opposite what is disclosed in Apte. 

It is therefore submitted that the combination of Apte and Masuda fails to show all of the 
features claim 26 and, therefore, no prima facie case of obviousness has been made out. 

The Examiner rejects claim 26 as not clear by what is meant by "display a password" (see 
point 8 at page 5 of the final action). Applicant initially points out that claim 26 does not use these 
words, but instead the words "display said password". This is anteceded by an earlier portion of the 
claim which states "receive a message over said connection with a universal resource locator (URL) 
and password". 

It is submitted that, in conjunction with the earlier anteceding portion of claim 26, the words 
"display said password" are clear in what is meant. 

Applicant therefore traverses the rejection of claim 26 under 35 USC 1 12. 
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Claim 29 

Claim 29 requires "determining an appropriate chargeable telephone number based upon said 
purchase amount". 

The Examiner relies upon paragraphs 20 and 21 of Furman and figure 2A as showing this 

feature. 

With reference to figures 2A to 2C, in Furman, a "customer places order" (202) and in 
response the "vendor transmits transaction identifier and 900 # to customer" (206). The "customer 
places telephone call to specified 900 #" (208) and "transmits transaction identifier to audio 
browsing platform" (216). The "audio browsing platform transmits transaction identifier to vendor 
server" (222) and the "vendor server transmits price to audio browsing platform" (226). The "audio 
browsing platform communicates price to customer" (228). If the price is accepted (232), the "audio 
browsing platform transmits amount to bill customer to 900 billing node" (240). 

As explained in paragraph 21 of Furman: "The 900 telephone number may be shared by a 
number of vendors" or "the 900 number could be dedicated to a particular vendor such that each 
vendor has its own dedicated 900 number." 

Therefore, in contrast to claim 29, in Furman the 900 number is selected independently of the 
purchase amount. 

The Examiner relies upon Matsuda merely to show access information comprising a URL 
and a password. Therefore, Matsuda also does not show "determining an appropriate chargeable 
telephone number based upon said purchase amount", as required by claim 29. 
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Since the references relied upon by the Examiner do not show all of the features of claim 29, 
it is submitted that the Examiner has not made out a prima facie case of obviousness against claim 
29. 

Claim 33 

Claim 33 requires "determining an appropriate chargeable telephone number based upon said 
purchase amount". 

The Examiner relies upon paragraphs 20 and 21 of Furman and figure 2A as showing this 
feature. The Examiner relies on Paik as showing caller identity information comprising at least one 
of a caller line identification (CLID) and a calling party name display (CPND). 

With reference to figures 2A to 2C, in Furman, a "customer places order" (202) and in 
response the 'Vendor transmits transaction identifier and 900 # to customer" (206). The "customer 
places telephone call to specified 900 #" (208) and "transmits transaction identifier to audio 
browsing platform" (216). The "audio browsing platform transmits transaction identifier to vendor 
server" (222) and the "vendor server transmits price to audio browsing platform" (226). The "audio 
browsing platform conmiunicates price to customer" (228). If the price is accepted (232), the "audio 
browsing platform transmits amount to bill customer to 900 billing node" (240). 

As explained in paragraph 21 of Furman: "The 900 telephone number may be shared by a 
number of vendors" or "the 900 number could be dedicated to a particular vendor such that each 
vendor has its own dedicated 900 number." 

Therefore, in contrast to claim 33, in Furman the 900 number is selected independently of the 
purchase amount. Furthermore, Paik has no disclosure relevant to this feature. 
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It is therefore submitted that the Examiner has not shown all of the claimed features in the 
references. In consequence, it is submitted the Examiner has not established a prima facie case of 
obviousness against claim 33. 

Claim 36 

The Examiner rejects claim 36 on the basis that "[t]he specification as originally filed 
contains no support for 'lack of modem'" (see point 7 at page 5 of the final action). 

Applicant traverses this rejection and points to the specification, as originally filed, at page 
13, lines 22 to 23: "Where the setup applet determines (figure 8, at S807) that the client does not 
have a modem". 

The Examiner rejects claim 36 as vague and ambiguous and failing to distinctly claim the 
subject matter which applicant regards as the invention (see point 8 at page 5 of the final action). 

The Examiner has not pointed out any part of claim 36 which is vague or ambiguous and has 
not pointed out any part of claim 36 which fails to distinctly claim the subject matter which applicant 
regards as the invention. For this reason alone, it is submitted that the Examiner's objection is 
improper. Furthermore, Applicant submits that claim 36 reflects the method described at page 13, 
lines 22 to 25 of the specification as originally filed and that the claim is in full compliance with 35 
use 112. 

For the foregoing reasons, Applicant traverses the rejections of claim 36 under 35 USC 112. 
Claims Appendix 

An appendix is attached containing a copy of the claims involved in the appeal. 
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Evidence Appendix 

None. 



Related Proceedings Appendix 



None. 
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CLAIMS APPENDIX 

(Claims on Appeal) 

1 . A method for enhancing security of network transactions, comprising: 

receiving information relating to a pending transaction between a vendor server and a client; 

receiving private network access information for accessing a private network and a 
transaction identifier from a transaction server system; 

provisioning a set of computer readable instructions with transaction-specific information 
comprising said transaction identifier and said private network access information; 

sending a message addressed to said cUent over said public Intemet with said set of computer 
readable instructions having said transaction-specific information, said set of computer readable 
instructions comprising access instructions for connecting said cUent to said transaction server 
system on said private network such that sensitive information relating to said transaction is 
directed to said transaction server system. 

4. The method of claim 1 wherein said information relating to a pending transaction comprises a 
vendor identifier and a purchase amount. 

5. The method of claim 4 wherein said private network access information comprises a flat rate 
telephone number. 

6. The method of claim 4 wherein said private network access information comprises a fixed charge 
per minute telephone number and a number of minutes. 

7. The method of claim 1 further comprising, prior to said sending, sending a location of said set of 
computer readable instructions over said public Intemet. 
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8. The method of claim 7 wherein said location is a universal resource locator ("URL"). 

9. The method of claim 7 wherein said location of said set of computer readable instructions is sent 
to one of said vendor server and said client. 

10. The method of claim 1 wherein said set of computer readable instructions comprise a first code 
segment which, when loaded into a processor of said client, cause said client to access said 
transaction server system on said private network. 

1 1 . The method of claim 10 wherein said set of computer readable instructions comprise a second 
code segment which, when loaded into said processor of said client, cause said client to pass said 
transaction-specific information to said transaction server system. 

12. A method for enhancing security of network transactions, comprising: 

receiving, over a public Intemet, information relating to a pending transaction between a 
vendor server and a client; 

sending a message addressed to said client over said public Intemet with a set of computer 
readable instructions having transaction-specific information, said set of computer readable 
instructions comprising access instructions for connecting said client to a transaction server system 
on a private network such that sensitive information relating to said transaction is directed to said 
transaction server system; 

wherein said message is a transaction message and further comprising, prior to said sending 
said transaction message, sending a set-up message addressed to said cUent over said pubUc Intemet 
with a set of computer executable instructions for determining resources of said client for connecting 
to said private network. 
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13. The method of claim 12 further comprising receiving from said client over said public Internet 
an indication of resources of said client and provisioning said set of computer readable instructions 
based, in part, on said indication of resources. 

14. The method of claim 1 wherein said set of computer readable instructions further comprises 
instructions for determining resources of said client for connecting to said private network. 

15. The method of claim 1 further comprising sending said information relating to a pending 
transaction to said transaction server system over a secure link prior to said receiving a transaction 
identifier and private network access information. 

16. The method of claim 4 wherein said information relating to a pending transaction further 
comprises a location of a data product which is subject of said pending transaction and access codes 
for use in accessing said data product. 

17. The method of claim 4 wherein said information relating to a pending transaction includes an 
intemet protocol ("IP") address of said client and wherein said private network access information 
comprises an IP address which an intemet service provider ('TSP") of said client maps to a port 
connected over said private network to said transaction server system. 

18. The method of claim 1 wherein said receiving and said sending are performed at a web server 
and further comprising, at a transaction server system: 

receiving customer-sensitive information and transaction identification information 
consequent upon execution of said set of computer readable instructions at a client; 
selectively sending transaction approval information. 

19. A computer-readable medium storing statements and instructions for use in the execution in a 
web server of the method of claim 1 . 
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20. A web server adapted for performing the method of claim 1 . 

21 . A method for enhancing security of network purchase transactions, comprising: 

receiving, over a public Intemet, information relating to a pending purchase transaction 
between a vendor server and a client; 

sending a message addressed to said client over said public Intemet with a set of computer 
executable instructions for determining resources of said client for connecting to a private network. 

22. A method for enhancing security of network transactions, comprising: 

receiving information relating to a pending transaction over a secure link, said information 
including access information for a data product, and a purchase amount; 

determining an appropriate chargeable telephone number based upon said purchase amount; 

storing a transaction identifier, said telephone number, and said access information; and 
retuming said transaction identifier and said telephone number over said secure link. 

23. The method of claim 22 further comprising: 

receiving a telephone call made to said telephone number from a caller; 

during said call, receiving caller identity information; 

during said call, receiving said transaction identifier; 

storing said caller identity information with said transaction identifier; 

providing said access information to said data product to said caller. 

24. The method of claim 23 wherein said telephone number is a flat rate number. 

25. The method of claim 23 wherein said telephone number is a fixed charge per minute number 
and wherein said determining further comprises determining a number of minutes based on said 
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purchase amount and storing said number of minutes. 

26. A computer readable medium storing computer-readable instructions which, when read by a 
client, cause the client to: 

dial and establish a connection to a specific telephone number over a telephone network; 

send a transaction-specific identifier over said connection; 

receive a message over said connection with a universal resource locator (URL) and 
password; 

drop said connection; 

connect to said URL over a public Internet; and 
display said password. 

28. The method of claim 22 wherein said secure link is a data network link. 

29. The method of claim 22 wherein said access information comprises a URL and a password. 

30. The method of claim 22 wherein said receiving comprises receiving said transaction identifier. 

3L The method of claim 22 wherein said receiving, said determining, said storing, and said 
retuming are undertaken at a transaction server system. 

32. The method of claim 3 1 wherein said receiving is receiving from a facilitation server and said 
retuming is retuming to said facilitation server. 

33. The method of claim 23 wherein said caller identity information comprises at least one of a 
caller line identification (CLID) and a calling party name display (CPND). 

34. The method of claim 1 wherein said receiving is receiving over a public Intemet. 
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35. The method of claim 16 wherein said information relating to a pending transaction further 
comprises said transaction identifier. 

36. The method of claim 1 3 wherein said indication of resources indicates said client lacks a modem 
and wherein said provisioning comprises provisioning said set of computer readable instructions so 
as to cause a display of said client to display said access instructions and said transaction identifier. 



